1979 5.09 1981

Vol.5 n°9 (#49) october 1980

Vol.5 n°9 (#49) october 1980

(ddj_1980_10.jpg)

p.4 Even Further with Tiny BASIC (p.356 in reprint volume 5)

p.4 Even Further with Tiny BASIC (p.356 in reprint volume 5)

[author : Robert Hudson] #Listing #BASIC #assembly #Programming

Extract : «  [...] Tiny BASIC was originally a concept of Dennis Allison’s and was actually the foundation which helped to create Dr. Dobb’s Journal. The first few issues of Dr. Dobb’s covered the theory of the tiny interpreters. I became intrigued with Tiny about a year ago, but had time to delve into it only recently. What really intrigued me were the two levels of interpretation. By this I mean the tiny BASIC interpreter is written in an Intermediate Language (IL), not machine code. The Intermediate Language is interpreted (read and decoded) by machine language routines. And since the IL is well defined with operation codes and addressing schemes, all the user has to do to change, alter, or add to a particular version is to redefine the IL program. [...]  »

p.12 Microcomputers as They Should Be (p.364 in reprint volume 5)

p.12 Microcomputers as They Should Be (p.364 in reprint volume 5)

[author : Olav Naess] #Computer #Interface

Extract : «  The microcomputer has great potental for interacting with the real world as well as for expanding into a large computer system by addition of various storage units, computing units, interface units, etc.

But the microcomputer systems of today are far from able to realize the potential for interfacing and expansion, or at least they implement such potential in an unnecessarily awkward way. It seems to me that the main reason for this is bad mechanical design. The mechanical problems evidently tend to escape attention. I will therefore try to throw some light upon these problems, and suggest solutions for them. The intention behind this article is to create widespread dissatisfaction with present designs, so that those with powers to bring about such reforms will be induced to get moving. [...]  »

p.16 CP/M to UCSD PASCAL File Conversion (p.367 in reprint volume 5)

p.16 CP/M to UCSD PASCAL File Conversion (p.367 in reprint volume 5)

[author : Tor Sjowall] #Listing #Pascal #Encoding

Extract : «  We were all very pleased with the article on PASCAL to CP/M file conversion in Dr. Dobb’s, but there is also a need to go the other way; to use CP/M 2.0 files in the PASCAL II.0 environment.

In order to get at the CP/M files, you have to access the diskette on a direct track/sector basis because of the difference betweeen CP/M and PASCAL file formats. This is not possible under the PASCAL system as described in UCSD’s manual but there is something they have not told us about the UNITREAD and UNITWRITE intrinsic procedures. [...]  »

p.20 Extended Source-Text Area and Label Capability for SC/MP NIBASM (p.371 in reprint volume 5)

p.20 Extended Source-Text Area and Label Capability for SC/MP NIBASM (p.371 in reprint volume 5)

[author : W. F. Long] #Programming

Extract : «  Are you using Roger Marin’s SC/MP assembler (SL0060) written in NIBL BASIC 1 ? Would you like to be able to expand the source-text RAM area beyond one 4K page for larger programs? Do you find that 26 labels aren’t enough or that you need to begin two with the same alphabetic character? If you answered “yes,” read on.

The following modifications are simple and brief. Together, they affect four existing lines and add one new line. Separately, the two extensions affect different lines and do not interact. They may be added singly if desired.

Expanded NIBASM reads source text across any allowable number of 4K pages consecutively from the starting address. (NIBL defines page 7 as the upper limit and you must remember to save space for generated object code.) Label capacity is doubled by permission of the entire lower-case alphabet as beginning characters. [...]  »

p.22 Opcode Design: 9 or 16 Bits? (p.373 in reprint volume 5)

p.22 Opcode Design: 9 or 16 Bits? (p.373 in reprint volume 5)

[author : H. T. Gordon] #Microprocessor #Programming

Extract : «  [...] The rational purpose of this note is to explore in depth a problem lightly touched on in my Kilobaud essay: how can one create, for an 8-bit CPU, more than the 256 possible one-byte opcodes? It is well-known that the Z-80 was the first design to use a “leading byte” (one of four different bit-patterns unused by the 8080) to endow the next byte with an utterly different meaning (from what it would have had standingalone). The effect is to create 1024 possible two-byte codes, most of them not defined at the higher level of Z-80 assembler language. [...]  »

p.24 MFT: A Multiple File Transfer Utility (p.375 in reprint volume 5)

p.24 MFT: A Multiple File Transfer Utility (p.375 in reprint volume 5)

[author : Lawrence E. Hughes] #Listing #Assembly #Storage #DataManagement

Extract : «  This article describes the design and use of a utility which makes it practical to use a single disk drive on the Digital Research CP/M operating system. The entire source is included in this article, and is also available from the author on an 8" single density, 128-byte sector diskette, along with a few other public domain programs, from the above address, for $15. I hereby release MFT into the public domain, for use on any CP/M (or other) system. No right is granted for resale, with or without modifications. [...]  »

p.32 A Cross Reference Program for Northstar BASIC (p.382 in reprint volume 5)

p.32 A Cross Reference Program for Northstar BASIC (p.382 in reprint volume 5)

[author : Larry Hudson] #Listing #Assembly #Algorithm #Programming

Extract : «  Here is a combined line number and variable cross referencing program for Northstar BASIC. Because this is a machine language program, it runs much faster than the others I have seen which were written in BASIC. This one will do a 500 line program in about 30 seconds.

I have tried to write it to be as general as possible. All I/O is through the normal Northstar DOS I/O, and naturally the disk routines are through the DOS. All other subroutines are within this program. The output routine uses the standard Northstar convention of specifying the output device by the code in the accumulator. As it is written now, it uses 0 for the console device and 1 for a hard-copy device. These numbers can easily be changed if needed. [...]  »

p.42 Solution of Three First Order Differential Equations with an SR-52 Programmable Calculator (p.392 in reprint volume 5)

p.42 Solution of Three First Order Differential Equations with an SR-52 Programmable Calculator (p.392 in reprint volume 5)

[author : S. Andrew Yakush] #Mathematics #TI #Book

Extract : «  In mathematical modeling and especially the area of biological modeling, effective models have been developed using three first order ordinary differential equations of the form:

x' = f(t, x, y, z) x(t0) = x0

y' = g(t, x, y, z) y(t0) = y0

z' = h(t, x, y, z) z(t0) = z0

It is often helpful to be able to do some preliminary examination of the model before employing a computer to do the major simulation. This paper presents a program written for the Texas Instruments SR-52 programmable calculator to solve this set of equations using a 4th order Runga-Kutta method [...]  »