#Robotics #ArtificialIntelligence
Extract : « A company which claims it is ready to manufacture and sell truly intelligent household androids, or robots, within the next two years—to the tune of $4,000 apiece—has the nation’s artificial intelligence experts up in arms. The experts unanimously state that the claims are fraudulent. The company, Quasar Industries located in Rutherford, NJ, is currently touring shopping centers around the country with a model of an android which they claim comprehends 4,000 words of vocabulary and can vacuum, wash dishes, and teach the kids French. Crowds in the sundry department stores are dazzled, according to numerous press reports. This robot is a fake, according to scientists from Carnegie-Mellon University in Pittsburgh, PA. The scientists recently undetook a first-hand investigation of the matter and found the robot to be a “radio-controlled puppet.” [...] »
[author : H.T. Gordon] #Listing #Assembly #Encoding #Programming
Extract : « While some of your readers may have become as weary as lam with my repeated attacks on the 650X legality-bytecount problem, this is in a way a programming guinea-pig for working-out optimization principles, relevant to all problems. Even your non-650X readers may find something of value in the enclosed MS, as it touches on some universal problems: the choice between decoding-logic or table-look-up programs, the extent to which subroutines should be designed to be nondestructive and purely-informative, and the uses of antibugging code. My ultimate goal is to develop scanning-debugging to a higher level. For this, the basic components of the debugger must be fast, efficient, and above al bug-free. [...]
On this subject, the chapters on antibugging, testing, and debugging in E. Yourdon’s Techniques of Program Structure and Design (Prentice-Hall, 1975) make interesting reading.
To sum up, tables can indeed play useful roles beyond their classic one of defining arbitrary relations and rules (such as the metalogical ASCII decision that $41 represents the letter A). These other roles have been obscured by the fact that it is simpler to implement a de novo calculation of a math function than a look-up in a gigantic table. With tables of more modest size, table look-up can (as Jim Butterfield suggested) maximize speed, at an acceptable (though relatively high) memory cost. When decoding logic proves to be very intricate (many small or unique classes) the use of tables may also be more code-efficient. Furthermore, programs may be easier to write because similar retrieval logic may be applicable to a variety of tables. There is probably some trade-off point (more that 35 bytes of decoding logic, more than 10 classes decoded?) where the entabling of pre-decoded information becomes an optimal solution of the dimensions of the table can be kept within reasonable bounds (no more than 32 bytes?). »
[author : James Monagan] #Listing #BASIC #Programming
Extract : « [...] The code to be searched or patched may reside anywhere in memory or on the reserved areas of the disk. These areas comprise the first five tracks and are occupied by the bootstrap/loader (sectors # 0,2,4,6) and by BASIC itself (remaining 156 sectors). [...] »
[author : Gary A. Kildall] #Programming
Extract : « One principal difficulty with newly evolving computer technology is that software generation tools generally lag corresponding hardware facilities, thus forcing the software engineer to resort to outmoded techniques to produce software systems.
The purpose here is to present one area of difficulty—that of a static program relocation—and to offer a simple solution which can be applied to nearly any microcomputer software environment where relocation is not supported by the manufacturer.
The need for static relocation arises most often in a situa tion where the software systems must be reconfigured in the field. For example, data entry equipment manufacturers often provide a range of optional peripherals which can be attached to user’s equipment as processing requirements change. Each peripheral usually requires a software “driver” which is device specific, and interfaces the device to the operation environment. [...]
References
Kildall, G., Microcomputer Software Design: A Checkpoint. Proceedings of the Fall Joint Computer Conference, 1975.
Knuth, D., The Art of Computer Programming. Volume I: Fundamental Algorithms. Addison-Wesley, Reading, MA, 1975 »
[author : Richard L. Roth] #Listing #Assembly #>Programming
Extract : « Once you start writing assembly language programs you will find every program requires certain functions. Some functions are so common, such as getting a character from the console terminal, that you can build them into a system monitor. This monitor can be put in PROM or loaded when you turn your machine on. But the large majority of common functions are only used for a class of programs. It’s wasteful to always have them around so you only have them in memory when you need them. During the stage of small programs and hand assembling, each time you want any of the common functions you must move it to the appropriate place and you must ‘relocate’ all absolute addresses, usually jumps and data. But as programs get bigger and as the number and kind of common modules grow, it behooves one to let the computer do the busy work of moving those modules. At the low level, if you separate your code from data, you might find a relocator that can move absolute code-fine for a 10 or 256 byte program. Not so fine for 4000 bytes, esp., since you must watch carefully to see if all the constants that look like addresses are not changed. The next step up is to have an assembler do the dirty work and start each program with a common set of routines, in source. At around 6-8K of program code, even this becomes unmanageable since just handling a source file that is 60K or 1000K can take 15 minutes just to read it off a floppy disk. Keeping track of a program becomes harder and harder as it gets bigger, a 2K program can have a 30 page listing if it’s well commented. The final answer is to produce an intermediate phase where the computer has converted all the code to internal form, i.e., the machine instructions are directly in hex or octal, but is still keeping track of jumps and other location dependent information. [...] »
[author : Gordon French & Gregory Yob] #Listing #Assembly #BASIC #Graphics
Extract : « A PHILOSOPHICAL RAMBLE
Our software is a tool for others to use. Rather than make a program capable of some special effects and little else, we provide two essential tools which make the TV Dazzler a genuine graphics display rather than a somewhat quirky toy.
Once having the tools, no dyed-in-the-wool hacker can resist using them. In that spirit we offer some demonstrations and hacks which evolved while we were making the programs. Bear in mind that our entry consists of the tools, and not the rather crude examples of how to use the tools. [...]
CONCLUSION
Here are some tools. Use them freely. If you study the line-drawer, you will note the use of recursion and stacks. This could be done in other possibly better ways, but the idea was a fine bit of fun!! As for the dot plotters, they are nearly optimal and stand as a challenge to the dedicated super-hacker. We mortals will potter about in BASIC.... »
[author : Phillip Simpson] #Listing #Assembly #BASIC #Graphics
Extract : « After reading Joe Sanger’s article Video Chase for the 8080/VDM (DDJ, May 1977), I began to wonder why all the software for video display devices is being written for VDM’s while I sit with my $200+ DAZZLER watching random color patterns. What happened to all those people who bought DAZZLER’s? Why aren’t they writing software for the rest of us?
The solution was, of course, obvious... the reason I spent all that money on this funny looking box with the blinking lights was for the fun!? of programming. So I undertook to convert CHASE for the DAZZLER. This accomplished, I broke out the subroutines used to drive the DAZZLER, added a few more bells and whistles and created a DAZZLER DRIVER. What follows is a description of the driver and my adaptation of CHASE! I’ve also included some examples to show how it can be used for display of moving objects and alphanumerics. It can even be used by a BASIC program. [...] »
[author : John MacDougall] #Listing #Assembly #Diagnostic
Extract : « [...] I have found this test program to be exceptionally good as well as fast. It even found a pattern sensitive 2102 that I had saved for the occasion from a previous hair tearing session. Keep up the good work! [...] »
[author : Tim Scully] #Listing #Assembly #Programming
Extract : « I have a Poly System 4 with 8K of RAM (from 2000H— 3FFFH). A few weeks ago I decided to get PILOT running on this system, and translated Dr. John A. Starkweather’s 8080 PILOT 1.1 (from May 1977 Dr. Dobb’s) so that it would live comfortably in Poly’s memory, starting at 2000H. After writing a few simple PILOT programs, the need for an editor was clear. Being short on memory, I didn’t have room for an elaborate editor program, I wanted to squeeze a mini-editor into the space between a jump to the start of PILOT at 2000H and the actual start of PILOT at 2100H.
The program listed below was hand assembled because Poly has neither an assembler nor a printer. [...] »
#Encoding
Extract : « [...] Octal appeared very early on the computer scene. The human brain seems to have something against long strings of repetitive characters. Binary, having only 2 character variations, reaches the rejection point very quickly. The limit seems to be about 6 bits, because most people who work with Baudot teletype soon learn to read the 5-unit code from punched tape, but very few ever learn more than a few characters of 7-unit ASCII. [...]Octal, therefore is purely a matter of convenience for the human in dealing with the blinkey beast.
The development of hex is a compromise. Since most applications of computers require some nibbling at, if not actual crunching of decimal numbers, most machines become proficient, via hardware instructions, at either XS3 or BCD arithmetic. [...] »