Old COBOL standards were based around 80-column punched cards, and columns beyond 71 (or 72) were reserved for line numbers. They were little used, but a numbered deck, if dropped, could be sorted by a collator.
Because of this, some compilers would not parse beyond a certain column (which could be 70, 71, or 72). So, in the interests of compatibility, it ...
Superior Software's "Speech" was a pure software speech synthesizer that ran on the BBC Micro (which used a 2MHz 6502A processor, so had slightly more raw processing power than typical 8-bit machines); it is described in detail on this page, which states it was inspired by similar programs on C64 and Spectrum that achieve it using sound chips (so ...
Why did the original Apple //e have two sets of inverse uppercase characters?
Simple: To allow lower case inverse letters.
It's all about the clever way Woz arranged the original II's single character set to save in hardware and offer additional functionality. There is only a single character set of 64 characters, showing up 4 times in 256 entry character ...
If you go back a lot before the x86, this technique wasn't unusual at all. In fact, writing programs using printable letters and symbols was pretty much the norm for early computers, except that there was a number of encodings for words of varying bit size, and that encoding was not ASCII.
On the IBM 1401 (1959), a program that looked like
First, there is a major caveat. Most of the iconic early voice synthesizers were not purely software systems. For example, the classic DECTalk system, famously the voice of the late Stephen Hawking, was a discrete unit that connected by serial RS-232. It is effectively a closed box that is sent ASCII text and generates line-level audio. Internally, I ...
The BASIC Programming cartridge for the Atari 2600 displayed twelve characters per line.
The RCA 1802-based VIP used bitmap graphics rather than having a "text mode" as such, but the typical bit map font was five pixels wide on a 64-pixel-wide screen.
Digital Research produced as one of their early attempts into graphical desktops (on their way to GEM) a basic portable graphics library - GSX. GSX did actually support proportional fonts, both in print and on-screen, and was included with the CP/M support in Amstrad machines running CP/M Plus. GSX was supported by two of DR's own applications, DR Draw and ...
There existed a Russian text-to-speech program written for the Elektronika BK-0010 in the early 1980s, whose length was 023500 bytes == 10048, mentioned in a list of application programs for the BK-0010 under the name of ГОВОРУН ("Chatterer", after a talking bird in a childrens' book/cartoon The Mystery of the Third Planet).
Its sound quality was ...
In the old days, I remember we were told to never go beyond the 70'th column in the text editor (the actual value was usually something above 70, but less than 80). [...] If it makes a difference, this was when programming COBOL.
No, it doesn't, as it was more of a feature of the underlaying priciples and standards for handling punch cards. By default ...
On the basis that a picture is worth a thousand words, I include my scan of a punched card:
As amply described in the other answers, it shows how the columns are visibly marked on the card for different purposes. It makes sense when you see a card. It makes less sense when you're using a computer display or are using paper tape!
I think the following early text editors meet your criteria:
Brian Tolliver’s TVEdit (Stanford, 1965), based on Doug Engelbart’s earlier word processor; see On-line Text Editing: a Survey:
TVEDIT is one of the earliest (1965) time-sharing, CRT-based text editors [12, 22]; it displays many lines of text at electronic speed. The user thus continually views ...
Is the 68000 a 16-bit CPU? :) To some it is, and therefore Say, from 1985, for the Commodore Amiga counts. It can be found on the Workbench disk. For more reading, look up the narrator.device interface on the AmigaOS wiki: https://wiki.amigaos.net/wiki/Narrator_Device
And here's Steamed Hams recreated using Say: https://www.youtube.com/watch?v=Rx6mJ4XY0oQ
This is an AppleSoft issue where it puts spaces either side of a token.
PET/CBM BASIC (based off the same code base) doesn't do this.
Tokenising ignores spaces, this means it can be difficult on the PET to see some of the problems that the tokeniser can cause.
For example LET AFOR=ONER gets parsed as LET A FOR = ON ER
Which is very difficult to see on a ...
Just the first (of many) example of using proportional fonts on Commodore64: https://youtu.be/k2NRlsopoOU?t=441
You couldn't really use a proportional font on the Spectrum because
the colour attributes were one background and one foreground for each
8x8 square. That meant that, practically speaking, each letter had to
be by itself in an 8x8 cell.
All text is painted as bitmaps.
The highest-resolution built-in mode is 640x200 pixels, so that provides an 80x25 text mode. 80-column modes were used in business software (e.g. DBase II) and even in the CP/M 2.2 and 3.0 OS.
The CPC uses a CRTC6845, which is wired up atypically to create linear scan lines but nevertheless can still hardware scroll in ...
CZ+SK ZX SW archive
In there are TTS engines for ZX Spectrum (1bit digital sound, no DAC, no FPU, no mul/div instructions, ~3.5 MHz 8bit Z80 CPU):
very simple asm, (portable to C/C++ see the link below), very low demands on CPU. It is not very good quality
much improved quality
its slightly worse than Kecal 2.3
ASCII was designed from the start with usable subsets (for instance an uppercase subset representable with six bits, consisting of the four central columns) and international variants. SHARE (IBM users' group) insisted that all characters needed for PL/I, included the vertical bar, were present in the uppercase subset(*). That was solved by allowing ! to ...
It was standard practice on the Sinclair ZX80 & ZX81 to put executable code into a REM statement at the beginning of a BASIC program.
REM statements are, of course, text comments, so this meets the spirit of your requirement for executable ASCII.
The ZX80 (1980) and ZX81 (1981) predate your question about the early 1990s by about 10 years and used the ...
It can be done in any environment that:
Allows the remarking of data files into program files,
Has a loader format that's either primitive enough or all readable
Has a character set (doesn't have to be ASCII) that has a sufficient number of encodings that produce valid opcodes
Has an address space layout that fits the possible encodings
Here is a program I wrote several years ago in AppleSoft for the fun of it. What it simply does is disassemble itself from the tokenized storage into a listing. If you run it, it will look the same as if you did a LIST command.
In general, this gives you all the rules of AppleSoft formatting but in the form of a program :-)
0 REM ** DISASSEMBLE MYSELF
Depends on your definition of a microcomputer, but e.g. Sharp PC 1210 (and derivatives) had 24 characters per (one) line.
PMI-80 had 9 characters per line, but you might not consider it a true microcomputer.
Really early computers like the Mark I and ENIAC didn't have enough memory to attempt to handle text; also the use-case was mostly calculations.
A number of decimal IBM computers used characters (with 5 or 6 usable bits) as the basic unit, and decimal digits were just a special usage of those characters:
The IBM 1401 computer, and its compatible successors ...
Back in 1986, a company called Berkeley Softworks released a GUI desktop environment called GEOS for the Commodore 64. It was later ported to the Commodore 128, the Commodore Plus/4, and Apple II.
GEOS was obviously inspired by the classic Mac OS desktop. It implements all the basic elements one would expect from such environment, such as a pointer-driven ...
"Character memory" is the bitmapped definitions for each of the characters (e.g. "glyphs") that are displayed in text mode, based on the "character codes" that are poked into the "screen memory".
Depending on which graphics mode you enable, there are several different memory areas that will be accessed by the VIC-II in creating the display. If we only focus ...
No 8-bit computer (back then) did support proportional fonts out of the box, but there where some programs on next every bitmap capable 8 bit computer, I this might as well include the Spectrum.
For the Apple II support was added by Apple rather early. Already the Apple DOS Toolkit included a utility called HRCG or High Resolution Character Generator, ...
I remember doing this on the university mainframe around 1975. This was on an ICL1904S. Note that the 1900 series had been around for more than 10 years at that time. I don't know when the feature came out but it had been around for some time.
You could list out any executable in card reader format. It would produce the executable in 6-bit characters in ...
To elaborate on drawing text on Amstrad CPC and its screen addressing:
The first row of every character position on screen is at the memory address range from &c000 to &c7ff, and thus can be calculated as &c000 + y * 80 + x.
FOR I=&C000 to &C7FF: POKE I, &FF: NEXT
The subsequent lines of every character are &800 bytes apart ...
It's really more of a conjecture, but if it is considered suitable as an answer:
Already in early TECO, the letter q ("quantity") was used to retrieve the value of a register. That might have been the reason to call them Q-registers.
Trying to trace reasons for why things are named a certain way is always difficult; they way this usually goes is that ...
For a slightly interesting twist on this concept, consider Control Data mainframes.
These beasts included not only a CPU, but a "peripheral processing unit" (PPU)1--and the CPU sent commands to the PPU via normal I/O channels.
The CPU was a 60-bit processor that used 6-bit character codes. The PPUs were 12-bit processors, so the CPU sent a stream of 2 ...
The screen character set on the Apple II looks like this:
00-1f: ASCII 40-5f, but inverse text
20-3f: ASCII 20-3f, but inverse text
40-5f: ASCII 40-5f, but flashing text
60-7f: ASCII 20-3f, but flashing text
80-9f: ASCII 40-5f (officially control characters, but displayed as normal text)
a0-bf: ASCII 20-3f
c0-df: ASCII 40-5f
e0-ff: ASCII 20-3f (Apple ][/][+)...